On Thu, 11 Mar 1999 22:03:44 +0800, Gordon <gbe### [at] birdcameroncomau> wrote:
>I've found that doing what Ken has done usually works. You can usually use
>differences to chop bits off meshes. If you try to reverse the difference,
>take the mesh from the sphere, it doesn't quite work though. The mesh
>appears as an infinitely thin surface (which makes sense I guess) and
>appears to behave as such in CSGs.

Are you sure?  It seems it should work the other way, since meshes
are defined to have no inside.  Difference is just intersection with
an inverse, so I'll use intersection to explain:

What intersection does is find all ray-object intersections with each 
component object, then filter the results so only the intersections
that are inside all other component objects are returned.  Since
nothing is inside a mesh, all intersections with non-mesh objects
should be ignored.  Intersections with the mesh object would survive.
The result seems like it would be quite unlike an intersection.

difference{sphere{...}mesh{...}} would return all intersections
with the sphere, plus whatever mesh surfaces fall inside the sphere.
For opaque objects, the result should be a sphere.

difference{mesh{...}sphere{...}} would return whatever intersections
with the mesh fall outside the sphere, but no intersections with the
sphere.  The result would be a hole in your mesh, not a spherical
cutout.

>On the topic in general, I would think the method of using the normals to
>determine the "inside" was more useful as this way open meshes could also be
>used. I still have a little trouble picturing how this would work exactly
>though!

Quite simply, it wouldn't really.  The "inside" of such a mesh would not
be well-defined, as whether a given point were inside or outside would
depend on which triangle it hit when testing.  Some points would always
be inside, of course, and some outside, but for anything but a simple flat
mesh you'd have lots of points that were undefined.

Post a reply to this message